Many organizations implement an enterprise portal to host internal and external applications. A portal is an application which aggregates applications together in a presentable format. Beyond merely being a presentation layer, a portal (or portal application) typically allows users to customize the presentation, including what applications to display. A portal can also provide a convenient single sign-on mechanism for users.
In general, portlets, one of the building blocks of portals, started to become popular with developers and programmers after the first version of the Java Portlet Specification (JSR 168) was released in 2003. Many vendors in the Java portal space, both commercial and open-source vendors, have implemented this standard, and developers have written portlets using the Java Portlet Application Programming Interface (API). JSR 168, however, stopped at defining the overall user interface (UI) component model, and did not define means for building integrated composite applications out of these components. Many limitations from JSR 168 were addressed with the release of Java Portlet Specification version 2.0 (JSR 286).
The main new features of JSR 286 are the capabilities for coordination between different portlets that can be implemented by different parties and packaged in different web application archive (WAR) files. Specifically, the coordination features of JSR 286 are based on a publish/subscribe model that does not request different portlet developers to know about each other's work. At development time, only data an individual portlet understands is defined, and the actual connections between portlets are created at deployment or at runtime. Leveraging these features, portal administrators or business users can build composite applications out of portlet components without predefined programming—for example, the portals described above.
Previous methods of communication between the portal application and the Portlet Container included embedding the Portlet Container within the portal application, such that the portal application and the Portlet Container are the same component. In these instances, communication between the portal application and the Portlet Container can be handled internally by the combined component, and no additional communication definitions or operations need to be defined. However, this solution applies several restrictions to a solution—namely, to change the portal application, a new portlet container must be defined in order to correspond to the modified portal application. Thus, modifications to either component cause significant hardship to developers and make ongoing integration of the components, or later modification to either of the components, difficult.